I don't think algebraic simplification can work without strong typing which kOS doesn't have. As while it should work for any scalar operations and most vector operations it likely breaks down once directions are are in the equations. This would be a basic example where it could break down for a vector operation x*x*x when x is a vector as x^3 is not a valid operation on a vector. And this below would be where it would give the wrong answer for combined vector and direction operations:

LOCAL a IS v(1,0,0).
LOCAL b IS r(0,90,0).
LOCAL c IS r(0,0,90).

PRINT c * a + b * a.  //should be about v(0,1,-1)
PRINT a * (c + b).    //algebraically expected to be about the same as above but is actually about v(0,1,0)

I have not compiled your branch with the optimizer to check and see if they actually do what I think they will or if would need to construct more elaborate cases. If you can successfully do type inference these cases can be caught but I would believe that is not easy to do.

I don't think algebraic simplification can work without strong typing which kOS doesn't have. As while it should work for any scalar operations and most vector operations it likely breaks down once directions are are in the equations. This would be a basic example where it could break down for a vector operation x*x*x when x is a vector as x^3 is not a valid operation on a vector. And this below would be where it would give the wrong answer for combined vector and direction operations:

LOCAL a IS v(1,0,0).
LOCAL b IS r(0,90,0).
LOCAL c IS r(0,0,90).

PRINT c * a + b * a.  //should be about v(0,1,-1)
PRINT a * (c + b).    //algebraically expected to be about the same as above but is actually about v(0,1,0)

I have not compiled your branch with the optimizer to check and see if they actually do what I think they will or if would need to construct more elaborate cases. If you can successfully do type inference these cases can be caught but I would believe that is not easy to do.

Oh shoot, you're absolutely right. The unit test environment doesn't work with non-scalars, so I had gotten complacent and forgotten about the other types where add and mul are valid operators but do different things. I had considered adding a type inference system, which you're right will be needed for algebraic reduction. That will come with formalizing an SSA form and rewriting the reaching definitions used in the constant propagation pass, which is currently quite messy.
Another next step should also be to extend the kOS encapsulated types to work in the unit test environment so that the type inference system can actually be verified.

Regarding type inference, I think the easiest option is to leverage the strongly-typed environment in which the code is being compiled. We would extend FunctionAttribute to add a (possibly optional) return type. While I'm at it, I would also add a property to indicate to the compiler that the method does not depend on game state and can be called at compile time if the inputs are immutable. For suffix accesses, if the incoming object type is known, the generic type argument of a given suffix can easily be found through reflection (perhaps cached in Structure.AddSuffix for snappier compiling). Those two easy-to-implement things should cover most of the work.
The harder part will be handling the Calculator classes. I think I would add a second method to Calculator to overload GetCalculator to work with two Types. I would also add abstract methods for the operations, taking two Types as operands. In implementation, these would mirror the structure of their 'real' methods and return the Type of the object it would expect to return.
Also, I take back my criticism of the limitations of the unit test environment not working for Vectors and Directions. I see now that that's to avoid invoking things that involve the UnityEngine, which don't work when the game isn't running.